As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Increasingly, information handling systems are deployed in architectures that allow multiple operating systems to run on a single information handling system. Labeled “virtualization,” this type of information handling system architecture decouples software from hardware and presents a logical view of physical hardware to software. In a virtualized information handling system, a single server can act and behave as multiple, independent servers. Server virtualization is enabled primarily by a piece of software, often called the hypervisor, that sits between the server hardware and the multiple operating systems, also called guest operating systems (guest OS). The hypervisor software provides a container that presents a logical hardware interface to the guest operating systems. An individual guest operating system, along with any applications or other software running on it, “thinks” it is running on a physical server and is known as a virtual machine.
Often, these architectures are employed for numerous reasons, e.g., (1) increased hardware resource utilization; (2) cost-effective scalability across a common, standards-based infrastructure; (3) workload portability across multiple servers; (4) streamlining of application development by certifying to a common virtual interface rather than multiple implementations of physical hardware; and/or (5) encapsulation of complex configurations into a file that is easily replicated and provisioned.
Internet Small Computer System Interface (iSCSI) and other storage transports may provide many advantages when operating in a virtualized environment, primarily because of the initiator addressing model that allows an initiator address to be tied to an instance of the operating system (e.g., virtual machine) instead of a hardware device, and provides numerous multiple implementation options. For example, iSCSI may be implemented in a virtualized environment as shown in either of FIGS. 1A and 1B.
FIG. 1A depicts an iSCSI implementation for a virtualized environment using an iSCSI offload host bus adapter (HBA). In FIG. 1A, an information handling system 10 may have one or more virtual machines 12 instantiated thereon. Each virtual machine 12 may interface with a hypervisor 14 that manages the individual virtual machines 12. Hypervisor 14 may interface with a host bus adapter 16 or network interface card. The host bus adapter 16 may include an iSCSI client that may serve as an initiator of iSCSI commands. If a network interface card is used for iSCSI the hypervisor 14 may include an iSCSI client implemented in software that may serve as an initiator of iSCSI commands. Information handling system 10 may be communicatively coupled to a storage array 20 including one more storage resources 22. In the implementation depicted in FIG. 1A, all storage resources 22 may be mapped to iSCSI client 16 in hypervisor 14 and all storage capacity may be provisioned by hypervisor 14 to the individual virtual machines 12.
FIG. 1B illustrates a “software initiator” implementation of iSCSI in a virtualized environment (e.g., for use with a TCP offload engine or an L2 network interface card). In FIG. 1B, an information handling system 30 may have one or more virtual machines 32 instantiated thereon. Each virtual machine 32 may include its own iSCSI client 36 that may serve as an initiator of an iSCSI commands. Each virtual machine 32 may also interface with a hypervisor 34 that manages the individual virtual machines 32. Hypervisor 34 may interface with a network interface card 38 in order to communicatively couple information handling system 30 a storage array 40 including one more storage resources 42. In the implementation depicted in FIG. 1, all storage resources 42 may be mapped to individual iSCSI clients 36, and thus individual storage resources 42 may be assigned to individual virtual machines 32 (e.g., storage resource 42a may be assigned to virtual machine 32a, storage resource 42b may be assigned to virtual machine 32b, and so on).
Some iSCSI implementations also allow offload, whereby a virtual machine instantiated on a particular information handling system is “migrated” to another information handling system. Offload may be desirable for many reasons, for example to allow a virtual machine to be moved from a first information handling system to a second information handling system in order to free up processing resources for other virtual machines instantiated on the first information handling system.
However, traditional virtualization architectures often do not allow seamless live migration of virtual machines between information handling systems that utilize different iSCSI implementations (e.g., migration from a “software initiator” implementation wherein initiators are present virtual machine clients to an implementation using iSCSI offload host bus adapter is not supported under traditional approaches).